Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Capture variables in tests and add logging. #942

Merged
merged 1 commit into from
May 31, 2022
Merged

Capture variables in tests and add logging. #942

merged 1 commit into from
May 31, 2022

Conversation

phbnf
Copy link
Contributor

@phbnf phbnf commented May 30, 2022

Capture variable in tests to execute them all. It also adds logging to see how tests have performed.

Checklist

@phbnf phbnf requested a review from a team as a code owner May 30, 2022 16:34
@phbnf phbnf requested review from smeiklej and pav-kv and removed request for a team May 30, 2022 16:34
@pav-kv
Copy link
Contributor

pav-kv commented May 30, 2022

My suggestion would be to remove fixchain/ratelimiter altogether instead. It uses rate.Limiter in a trivial way, so the latter can be used directly.

Copy link
Contributor

@pav-kv pav-kv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving to not block you, but see the removal suggestion.

@@ -42,13 +43,15 @@ func TestRateLimiterSingleThreaded(t *testing.T) {
if qps > float64(limit)*1.01 {
t.Errorf("#%d: Too many operations per second. Expected ~%d, got %f", i, limit, qps)
}
log.Infof("#%d: Expected ~%d, got %f", i, limit, qps)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is redundant. The expected value is part of the test name, and the qps only needs printing if it's not matching the expected value, which already happens 2 lines above.

Same below.

@@ -26,6 +26,7 @@ var testlimits = []int{1, 10, 50, 100, 1000}
func TestRateLimiterSingleThreaded(t *testing.T) {
for i, limit := range testlimits {
t.Run(fmt.Sprintf("%d ops/s", limit), func(t *testing.T) {
i, limit := i, limit
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch.

@pav-kv pav-kv removed the request for review from smeiklej May 30, 2022 20:08
@phbnf
Copy link
Contributor Author

phbnf commented May 31, 2022

+1 for removing them altogether. I have observed unexpected test failures where more than 2k operations per seconds happened, when there should never be more than 1k. Given the unpredictable behaviour of the current test code, I cannot tell for sure if it's because we're using rate.Limiter wrong, or if it was just a problem with the test. I would like to see the tests passing first in to gain confidence about our code. Then we can use rate.Limiter directly.

@phbnf phbnf merged commit 3362d9e into master May 31, 2022
@phbnf phbnf deleted the fix_test branch May 31, 2022 11:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants